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REMARKS 

Claims 15, 29 and 39 stand rejected under 35 U.S.C. §102 as being anticipated by WO 
97/19429 (Deluca et al.). These rejections are traversed for the following reasons. 

Independent claims 15, 29 and 39 respectively recite a method for handling messages 
transmitted between communication terminals via a wireless terminal, a communication terminal 
for handling messages, and a message format including a text part and at least one graphical part. 
These claims substantively recite a message including a text part and at least one graphical part, 
with the graphical part including a record for each of the at least one graphical part in a graphical 
format, and information in the message defining a position of the at least one graphical part 
relative to the text part. Importantly, claims 15, 29 and 30 recite that the message that is 
transmitted via the wireless network, not just the message that is eventually displayed, contains 
both a text part and a graphical part. This requirement, contrary to the Examiner's position as 
stated in the Final Rejection and the Advisory Action, is not anticipated by Deluca et al. 

Deluca et al. discloses a system in which messages are composed and transmitted to a receiving 
device in which a numerical code is utilized to identify an icon (prestored by the receiving device), 
with the code being selected by the composer of the message at the transmitting device. Upon 
receipt, the receiving device uses the numerical code to identify and retrieve the graphical icon from 
the memory of the receiving device, thereby eliminating a need to transmit any information to the 
receiving device beyond the numerical code to cause the display of the encoded icon in association 
with a text message. Deluca et al. does not teach or suggest that the transmitted message contains a 
graphical part, but rather discloses that the transmitted message contains only text (including the 
numerical code). According to Deluca et al., the graphical part corresponding to the transmitted 
numerical code is retrieved from memory and displayed after the message is received at the receiving 
device (see page 6, line 3 1 - page 7, line 3). Deluca et al. discloses only messages that include either 
(1) a numerical code (see page 5, lines 3-12); (2) a numerical code and any desired additional text to 
be displayed at the receiving device (see page 5, lines 13-26); or a numerical code and any desired 
additional numerals to be displayed at the receiving device (see page 5, line 27 - page 6, line 9). 
Deluca et al. discloses that the numerical code uses, for example, "predetermined characters 
commonly found on conventional telephone receivers" (page 3, lines 30-31). Such characters would 
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typically include the numerals "0-9" and the symbols "#" and "*." A person skilled in the art to 
which Deluca et al. and the present application pertain would understand that 'text" generally 
includes letters, numerals, and symbols (e.g., "#" and "*"). As such, a person skilled in the art would 
consider the messages taught by Deluca et al. to include only text. In fact, the Examiner states in the 
Final Office Action that "#07" (an example numerical code from Deluca et al.) is text. Therefore, the 
messages taught by Deluca et al. include only text and do not include a graphical part, and the 
recitation in claims 15, 29 and 30 that the message transmitted via the wireless network contains 
both a text part and a graphical part is not present in Deluca et al. 

The substantive recitation in claims 15, 29 and 39 that "position information in the message 
defin[es] a position of at least one graphical icon part in the text part" also has no counterpart in 
Deluca et al. The Examiner states in the Advisory Action that Deluca et al. discloses this recitation 
because arrangement of the images is based on the graphical icons' codes. However, the Examiner 
further states that Deluca et al. discloses that a graphical icon is always displayed on top of the text, 
hi contrast, the independent claims of the present application recite that the message itself includes 
position information that defines the relative position of the graphical icon part in the text part. As 
noted by the Examiner, the graphical icon of Deluca et al. is always displayed at the top of the text 
such that not only does Deluca et al. fail to teach or suggest the transmission of a message containing 
position information as recited by the independent claims, but there would be no reason to provide 
position information in the message since Deluca et al. does not contemplate differently positioning 
the graphical icon. For each of the foregoing reasons, it is respectfully submitted that the rejection 
of independent Claims 15, 29 and 39 is therefore overcome. 

Claims 16, 19-25, 30 and 33-38 stand rejected under 35 U.S.C. §103 as being unpatentable 
over United States Patent No. 6,032,025 (Sugio et al.) in view of United States Patent No. 
5,828,313 (Mochizuki). As previously stated, there is no suggestion or motivation to combine 
Sugio et al. and Mochizuki. However, even in combination, these grounds of rejection are 
traversed for the following reasons. 

Independent claims 16, 25, and 30 recite a message including a text part and at least one 
graphical icon part, with the graphical icon part including a record for each of the at least one 
graphical icon part in a graphical format and information in the message defining a position of 
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the at least one graphical icon part in the text part. As in claims 15, 29 and 30 discussed above, 
independent claims 16, 25 and 30 recite that the message that is transmitted via the wireless 
network contains both a text part and a graphical part. Again, this requirement, contrary to the 
Examiner's position as stated in the Final Rejection and the Advisory Action, has no counterpart 
in the proposed combination of Sugio et al. and Mochizuki. 

Sugio et al. discloses the display of a message, including a portrait image, on a receiving 
device. Similar to Deluca et al., the portrait image that is ultimately displayed on the receiving 
device of Sugio et al. is not contained in the message that is transmitted to the receiving device. 
Rather, the transmitted message contains an "image designating code/' which is analogous to the 
numerical code of Deluca et al. This image designating code of Sugio et al. causes the receiving 
device to retrieve from memory and display a portrait image corresponding to the transmitted 
and received image designating code (see Abstract; Col. 2, lines 30-56). Sugio et al. discloses 
that the message may include characters, numerals, and symbols (see Col. 2, lines 32-33). For 
example, a message may contain the numerals and symbols "*5*528," which causes a predefined 
portrait (i.e., portrait 28) to be displayed on the receiving device (see Col. 9, lines 24-34; Fig. 8). 
Additionally, Figs. 36A-36E (among others) and the corresponding description, indicate that 
only the image designating code (illustrated in the transmission code display section 243 and 
containing only numerals and symbols), and not the actual image itself, is transmitted (see Col. 
24, lines 39-42; Figs. 36A-E). 

Similarly, Mochizuki discloses that the transmitted message includes an "illustration 
code," which is a numeric code corresponding to a predefined illustration residing in the 
receiving device (see Col. 6, lines 39-45). As discussed above, a person skilled in the art would 
understand that "text" generally includes letters, numerals, and symbols (e.g., "#" and "*"). As such, 
a person skilled in the art would consider the messages taught by Sugio et al. and Mochizuki to 
include only text. As the messages taught by Sugio et al. and Mochizuki include only text and do not 
include a graphical part, the recitation in claims 16, 25 and 30 that the message transmitted via the 
wireless network contains both a text part and a graphical part therefore is not present in the 
combination of Sugio et al. and Mochizuki. 
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Independent claims 16, 25, and 30 recite that the at least one graphical icon part includes 
a record for each of the at least one graphical icon part in a graphical format. The Examiner 
states that Sugio et al. discloses arranging text and graphical parts of a compounded message in 
predefined positions and then further states that the Examiner has interpreted this predefined 
arrangement to be a graphical format. Contrary to the Examiner's position as stated in the Final 
Rejection and the Advisory Action, neither Sugio et al. nor Mochizuki, alone or in combination, 
teach or suggest that the transmitted message contains or defines a graphical format. The 
Examiner cites caselaw for the proposition that pending claims must be given their broadest 
reasonable interpretation consistent with the specification. However, the Examiner's 
interpretation that the predefined arrangement of text and graphics disclosed in Sugio et al. is a 
graphical format is neither reasonable nor consistent with the specification. A graphical format, 
as would be understood by one skilled in the art, defines how graphic objects are created and 
stored. For example, many different graphical formats exist, but most formats are considered 
either a vector graphic format or a raster graphic format (see Appendix: About File Formats, 
Montana State University Publications and Graphics, August 2001). A vector graphic format 
defines graphic objects using coordinate geometry, while a raster graphic format defines graphic 
objects using pixels (see id.). The Examiner's interpretation of a graphical format is neither 
consistent with the specification of Sugio et al, nor consistent with the understanding of one 
skilled in the art, and as such is an unreasonable interpretation. Both because the messages 
disclosed by Sugio et al. and Mochizuki do not contain a graphical part and because neither 
Sugio et al. nor Mochizuki teach or suggest a graphical format, the recitation of claims 16, 25 
and 30 that that the at least one graphical icon part includes a record for each of the at least one 
graphical icon part in a graphical format is not present in the combination of Sugio et al. and 
Mochizuki. 

For each of the foregoing reasons, it is respectfully submitted that the rejection of 
independent Claims 16, 25, and 30 is therefore overcome. 

Since Claims 19-24 and 33-38 depend from and include the recitations of a respective 
one of independent claims 16, 25 and 30, Sugio et al. and Mochizuki, alone or in combination, 
do not teach or suggest claims 19-24 and 33-38 for at least the same reasons as described above 
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with respect to independent claims 16, 25 and 30. Accordingly, the rejection of Claims 19-24 and 
33-38 is therefore overcome. 

Claims 17, 18, 26, 27, 28, 31 and 32 stand rejected under 35 U.S.C. §103 as being 
unpatentable over Sugio et al in view of Mochizuki further in view of United States Patent 
6,047,828 (Medina). As previously stated, there is no suggestion or motivation to combine Sugio 
et al., Mochizuki, and Medina. However, even in combination these grounds of rejection are 
traversed. Medina does not teach or suggest communicating via a wireless communication 
network, as is recited in the independent claims of the present application. Further, Medina does 
not teach or suggest a display message editor application, as is recited in at least claim 16 and 30. 
Further, Medina discloses using a standard telefacsimile data format for the graphics (see Col. 7, 
lines 19-20), rather than a graphical format as is recited in the independent claims of the present 
application. 

Claims 40-45 have been also added to more particularly define other unique aspects of 
the claimed invention. 

It is not believed that extensions of time or fees for net addition of claims are required, 
beyond those that may otherwise be provided for in documents accompanying this paper. 
However, in the event that additional extensions of time are necessary to allow consideration of 
this paper, such extensions are hereby petitioned under 37 CFR § 1 .136(a), and any fee required 
therefore (including fees for net addition of claims) is hereby authorized to be charged to Deposit 
Account No. 16-0605. 
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> MSU Publications and Graphics 
About File Formats 
File Format Basics 



As we move further along with the transition from paper-based media to electronic media, the sharing of electronic resources 
becomes increasingly important. Unfortunately, there is no single standard for all electronic files to ensure this process. In fact, the 
number of different electronic formats is quite large. In many cases this is due to a necessity for different file types to contain styles 
of information not supported by other formats. In some cases it is a matter software companies seeking competitive advantage. For 
users needing to share electronic files it can sometimes be a challenge to move these "inter-application," or between different 
software, and "cross-platform," from a PC to a Mac for instance. A newer challenge is moving from proprietary formats to the Web, 
which is platform independent through the use of HTML. 

Often the request to "just send me and electronic file" can be almost meaningless. There may be numerous electronic files that the 
requestor would not even be able to open. This is particularly true in the graphics and print production field where highly specialized 
software applications may require proprietary formats to support features not available in common applications. The classic example 
of this is page layout software. QuarkXpress is the industry standard for building and producing publications. But its feature set is so 
specialized that there is no way to save a Quark file and send it to someone so that they can open it with Microsoft Word. Another 
common example is the difference between Corel WordPerfect and Microsoft Word formats. Although each tries to be somewhat 
compatible with the other through a conversion process, there are still enough differences to make absolute conversion unreliable. 



More elaborate ways of achieving file exchange are often required. These usually involve trade-offs and limitations. There are stand- 
alone file translation utilities that can be very useful if you exchange files with other users with different applications or platforms. 
For most text and few graphic conversions these include software such as DataViz MacLink Plus for Macintosh users and DataViz 
Conversion Plus for PC users. For graphical formats, Adobe Photoshop has the ability to read and convert a wide variety of raster 
formats on either platform. Vector graphic format conversions tend to be more problematic due to the complexity of the format. For 
PC users one solution is IMS I HiJaak Pro. 



Fortunately, there are some common formats that are supported by most the major software applications. We'll discuss the categories 
related to graphics and text below. These all enable some degree of cross platform or inter-application compatibility and are the most 
useful for our purposes. 



Graphic Formats 



Graphic files can be created and saved using two completely different methods. These are called "vector" and "raster" and may exist 
either singularly or together as part of the same file format. 



Vector is method where graphics are created and stored as "objects" using coordinate geometry. Each object has attributes that 
govern how it will display. Vector images are usually comprised of numerous objects combined to collectively portray the overall 
image. 



One advantage of vector graphics is that they exhibit something called "device independent resolution." This simply means that they 
will always display or print at the highest-possible resolution since the image is transmitted mathematically to whatever display 
device is used. It also means that they can be scaled and modified in ways that will always preserve the highest image quality. Fonts 
are one example of vector graphics. Both Postscript Type 1 and TrueType fonts use vectors, also called outlines, to achieve the best 
possible display, at any point-size, to any printer. Adobe Illustrator is an example of a vector-based software application. There are 
numerous others and these are often referred to as "drawing" applications ~ as opposed to raster software which is generally referred 
to as "painting" applications. 



Raster graphics are created and stored using "pixels" to describe the image. Like the pieces of a jigsaw puzzle, pixels are the 
individual bits, or dots that collectively comprise the larger image. Each pixel has characteristics that affect how the image will look. 
These characteristics determine things such as whether the image is color, grayscale or line-art, or the amount of the resolution. 
Pixels are how scanners, computer monitors and digital cameras record and display information. Ultimately, even vector graphics 
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get converted to raster images when they are viewed on or printed. This process is called "rasterization." The device independence of 
vectors ensures that this will always happen at the highest pixel resolution. 

One strong advantage of raster graphics is that they are much better suited to depicting photographic or highly detailed images. A 
significant disadvantage is that raster images are much more dependent on resolution, which is a factor of their physical size often 
expressed in dots-per-inch (dpi), and they generally cannot be resized larger without diminishing their quality. Another disadvantage 
is that very large file sizes are required for high-resolution applications such as printing. Adobe Photoshop is an example of a raster- 
based software application. 

A note about extensions: file extensions such as the old DOS style suffixes are not required for Macintosh users but are still very 
helpful for PC users. It is highly recommended that all users should apply this convention in order to aid file compatibility. 

Postscript (PS or .ps) 

Adobe Postscript is a page description, or graphic imaging language. It is the primary technology that enabled and advanced the 
desktop publishing revolution. It is basically an ASCII text file that contains coded program language that instructs a graphic 
interpreter, such as a Postscript enabled printer, how to create an image. Whether it's page of type, a vector drawing, a raster image, 
or any combination thereof, it can be described by Postscript. Very few applications save files in pure Postscript format, but many 
applications include Postscript code as part of their file information. In many applications Postscript code is created-on-the-fly by the 
application when needed for printing. It is also useful as a print-to-disk file that can be downloaded to printers or used to distill PDF 
files. Only a few applications can "parse," or create images directly from Postscript files. Other applications will simply show the 
code, or do nothing. 

Encapsulated Postscript (EPS or .eps) 

You cannot generally view a Postscript formatted image - it is text file. However, when importing Postscript files into other 
applications, it is always useful to be able to see a representation of the image. Encapsulated Postscript is a variation of Postscript 
that also contains a preview image. This is by far a more common and useful version of Postscript and can be used by many 
applications as an exchangeable format. It is a highly recommended vector format. 

Tagged Image File Format (TIFF or .tif) 

TIFF is a high-resolution raster image file format that supports RGB, CMYK, grayscale and bitmap images. It is a very widely used 
format that is supported by most graphic applications and is ideal for cross-platform and inter-application exchange. It is also a 
highly favored format for photographs to be printed. TIFF does not use file compression in the base standard. However, it does work 
well with certain types of loss-less compression schemes such as LZW. When in doubt, make it a TIFF. 

Joint Photographic Experts Group (JPEG or jpg - also know as JFIF) 

JPEG is a very popular and useful format for raster images on the Internet. It is platform independent and can be exchanged among 
different computers. It supports both RGB and CMYK color modes and uses compression to minimize file sizes. The level of 
compression is configurable and can be optimized to maintain better image quality or smaller file sizes. In some cases it may be used 
for images intended for print. However, this must be done carefully since JPEG's compression is lossy, meaning it physically alters 
the image permanently by discarding information. This is more critical for print images. Moreover, continual re-saving in the JPEG 
format can compound the degradation. As a general rule, JPEG is best suited for Internet use. 

Graphics Interchange Format (GIF or .gif) 

This is the most popular format for raster images on the Internet. It is platform independent and can be exchanged among different 
computers. It only supports RGB color mode and must index colors to a color table. Consequently, although it does not support the 
highest image quality, it is an extremely efficient compressed format and displays flat color especially well. Compression is 
somewhat configurable by modifying the depth of the color table. In no case may the table contain more than 256 colors. It is not a 
useful format for working in print and is best suited exclusively to the Web. 

Device Independent Bitmap (BMP or .bmp - also known as DIB) 

This is the standard windows format for raster graphics. It is not a preferred production format since it does not support CMYK 
color. But due to prevalence of Windows it is a format that is frequently encountered. Professional graphic producers will typically 
convert these to other formats, such as TIFF, for the final production. BMP does support RGB, grayscale and bitmap modes. 

Portable Document Format (PDF or .pdf) 

This is a hybrid format based on Postscript that can contain both raster and vector information. It provides the highly compatible 
exchange of all kinds of documents across virtually all platforms. It is based on Adobe's Acrobat system of tools. In order to view 
PDFs the user must have the Adobe Acrobat Reader and associated operating system files installed. The reader and its Web browser 
plug-ins are freeware and are available from the Adobe Web site. To create PDFs a special printing driver or separate conversion 
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utility is required. This software is called Acrobat Exchange or Acrobat Distiller and is only available for purchase. 

PDF is an extremely useful format for what it does, but due to the necessity for it to do so many things, it does have limitations. One 
of these is a limited ability to edit or modify files once created ~ a very important aspect of print production workflow. It is a highly 
configurable format that can provide from low-to-high compression results depending on the fidelity of the match required for the 
exchange. Acrobat uses a font substitution scheme that may allow for some variation in appearance for the sake of file size. When 
working in professional print production, high fidelity requirements generally result in large file sizes. It is rapidly becoming a new 
preferred standard for dealing with professional pre-press work. It is not a recommended format when you need someone to be able 
to edit your file. 

Photoshop Document (PSD or .psd) 

Although the Photoshop format is a proprietary format, due to its prevalence as a standard image-editing application, it is an 
extremely useful format for exchange. The native PSD format is cross-platform and can be used by both Macs and PCs. The PSD 
format is primarily a raster format that provides extended support for features such as layering, alpha channels, true spot color, 
vector type and paths, and many other features. Converting a PSD to another raster format will "flatten" or disable many of these 
features. It is a highly recommended format where professional image editing may be required. 



Word Document (DOC or .doc) 

Due to the prevalence of Microsoft Word, its document format has become a de-facto standard for text exchange. This is a cross- 
platform format that can easily be shared between Mac and PC users. Some consideration much be given to font selection since 
these are not transportable with the file and may not match with other users who do not have the same font. Most print production 
shops will translate it into other formats for final production. 

Plain Text (.txt) 

Plain test is a bare bones, text-only format that virtually every word processing application supports. It is uses ASCII encoding for 
text characters and does not support any internal formatting for font selection or styles. It is a workhorse for text file exchange. 
When in doubt, make it Plain Text. 

There are also a couple of variations of Plain Text that can be useful when dealing with certain spreadsheet or database files. These 
include Tab-delimited Text and Comma-delimited Text. Both of these are still basic Plain Text files. 

Rich Text Format (RTF or .rft) 

RTF is a more robust ASCII text format that also supports some internal text styles and formatting, such as color, bold, italic, tabs, 
etc. RTF is not as widely supported as Plain Text. 

WordPerfect (WPD or .wpd) 

This is a proprietary word processing format. Due to limited compatibility features between Microsoft Word and WordPerfect, it is . 
still somewhat viable as an exchange format. Most print production shops do not use WordPerfect and will translate it into other 
formats for final production. 

Portable Document Format (PDF or .pdf) 

PDF is also a viable text exchange format. For more information, see the PDF description in the above graphic section. 
Hypertext Markup Language (HTML or .html - also .htm) 

HTML is the file format for Web pages. It is essentially a Plain Text format with special coded tags that control the display of text 
and graphics on a Web page. The key to HTML is the tags and understanding how to use them. There are numerous resources for 
this available on the Web. HTML files can be created manually using text editors or automatically by applications that create Web 
pages. Making sense of pure HTML pages can be difficult for non-programmers, though the plain text can be view by numerous 
applications, including the Web browsers themselves. By far the most common use for these files is for Web browsers to parse into 
formatted pages. Except for a few specialized cases, this is not a very useful format for file exchange. 

Written August 2001. 

Return to regular view B Text-only Updated: 7/28/2005 



Text Formats 



© Montana State University 2005 



Didn't Find it? Please use our contact list or our site index 



http://www.montana.edu/cpa/graphics/ugformats.htm 



10/4/2005 



